GitHub で議論するのは難しい

如何に。何故

でも別に要らなくない?

Approve したい (begin-commit)

信用が無い

變化させたくない

變化し辛いものは變化しない

無理な事を無理にやらない

勝手に變へられたくない

信用が無い

誰が書いたか

その情報なんで要るの?

信用が無い

icon でも置いとけば?

複數の文書を同時に變更出來る

Company handbooks frequently start as wikis. This format is more comfortable for people to work in than a static website with GitLab Merge Requests and GitLab Pages. However wikis tend to go stale over time, where they are badly organized and get out of date.

In wikis it is impossible to make proposals that touch multiple parts of a page and/or multiple pages. Therefore it is hard to reorganize the handbook. Because GitLab Merge Requests and GitLab Pages are based on distributed version control you can split the role of submitter and approver. This allows for a division of work that keeps the handbook up to date:

・Anyone who can read the handbook can make a proposal

・Leaders (who tend to be short on time) only have to approve such a proposal

Wikis also do not encourage collaboration on changes, because there is not way to discuss a proposed change like there is with merge requests.

發想する media ではない

公開用の文書なら好いでせうね

code もその一例ですよ

flow 情報なんて在るの?

箇條書きに構造化される

蒸し返せる

竝行に議論出來る

link を張れるかはこの話題では限定的

code の行に comment が出來るのは好い。これは優れてゐる

code は公開文書だから

機械に公開するんだ

人閒は雜。非公開文書を讀み書き出來る。公開文書は讀むのも書くのも苦手

そもそも code の snapshot ではなく差分に comment したい

thread は議論出來る形式ではない

分岐出來ない

竝行出來ない

蒸し返し出來ない

半二重通信。非同期ではない

複數の話題を纏めて thread にやり取りするのは面倒。思考を block する。だから思考も議論も抑制される

無理にやるから長大な時閒がかかる

同期的にはいっぺんに全部思考出來ないから、一つ解決したら次の議論をする。いっぺんにやれ

code に comment するのは、その code を讀んでる時に思ひ附いたから

まぁそれは好い。書くのも好い。議論を始めるな。書いた後直ぐに判る筈だ

會話も半二重通信

速度が壓倒的に違ふ

これが一番の利點

「怒ってない」「言ひ譯したい」みたいな身振りも傳へられる

これが次點

アジェンダが有れば論點が缺けるのは防げる

人數少なければ、論點が壓殺される事も少ない

少ないだけ。蒸し返しが難しいから。何故なら忘れる

もっともっと早く指摘されるべき

讀めてゐない時はよく有る

どうなん? と思った時に、議論しないといけない

議論が出來ない場所では議論が出來ない

同語反復ではない。しかし自明

なのでわかってる人しか review 出來ないまま經る。最惡

半二重通信

chat

會話

ごまかしが效く

e-mail

BBS

全二重通信

手紙

blog